[00:02.640 --> 00:06.700]  Hi, this is Austin Scott. And this is five quick wins for
[00:06.700 --> 00:11.200]  improving your ICS cybersecurity posture. I'm a Principal
[00:11.200 --> 00:14.240]  Industrial Penetration Tester as part of the Dragos
[00:14.240 --> 00:18.900]  Professional Services team. And I really see the world from the
[00:18.900 --> 00:22.760]  perspective as a pen tester, just like a hammer sees the
[00:22.760 --> 00:26.840]  world as a nail. I really see everything from an adversarial
[00:26.840 --> 00:30.860]  perspective. And that's the point of view we'll be taking in
[00:30.860 --> 00:34.840]  this presentation today. Really, we're looking for ways
[00:34.840 --> 00:39.220]  to make it more difficult for an adversary to move through an
[00:39.220 --> 00:42.820]  ICS environment. Now, my recommendations in and of
[00:42.820 --> 00:45.780]  themselves won't give you a bulletproof cybersecurity
[00:45.780 --> 00:49.780]  program or industrial cybersecurity program. But they
[00:49.780 --> 00:53.240]  will raise the bar for your security posture. Of course,
[00:53.240 --> 00:55.400]  there's a lot of other things involved in running an
[00:55.400 --> 00:58.800]  industrial cybersecurity program that are outside of the scope of
[00:58.800 --> 01:02.120]  this presentation. But in my presentation today, we're going
[01:02.120 --> 01:04.540]  to talk about a lot of the common things that as an
[01:04.540 --> 01:08.320]  industrial penetration tester, as an industrial cybersecurity
[01:08.320 --> 01:12.320]  assessment, practitioner, these are the things that we see over
[01:12.320 --> 01:15.740]  and over again. And a lot of them can be addressed fairly
[01:15.740 --> 01:21.200]  easily without a lot of capital or operational expenditure. So
[01:21.200 --> 01:24.840]  we'll talk about how to address some of these risks and what
[01:24.840 --> 01:30.400]  these common issues that we identify are. So a lot of this
[01:30.400 --> 01:36.500]  is based on the 2019 Dragos year in review report. We see a lot
[01:36.500 --> 01:40.980]  of these common issues as we do assessment after assessment.
[01:40.980 --> 01:46.440]  It's common to see things like limited visibility or credentials
[01:46.440 --> 01:50.540]  laying around or routable connections from your corporate
[01:50.540 --> 01:56.240]  environment into the ICS environment, and even ICS
[01:56.240 --> 01:59.900]  components directly accessible from the internet these days. So
[02:00.760 --> 02:03.180]  a lot of these common findings are highlighted in this year in
[02:03.180 --> 02:06.120]  review report. And we'll be talking about the top five and
[02:06.120 --> 02:10.400]  how to really address those or identify them in your own
[02:10.400 --> 02:16.440]  environment and remediate them. So we think it's important to
[02:16.440 --> 02:22.080]  take a threat-based approach when you're looking at risk in
[02:22.080 --> 02:27.300]  your industrial cybersecurity environment. Now within Dragos,
[02:27.300 --> 02:31.020]  we track a number of activity groups that target these
[02:31.020 --> 02:34.040]  environments. And this will be really done from the perspective
[02:34.040 --> 02:39.960]  of our own internal activity group called Kyberite, where we
[02:39.960 --> 02:44.500]  develop our ICS tactics and techniques, really based on a
[02:44.500 --> 02:46.700]  lot of the other activity groups that we see. So we try to do
[02:46.700 --> 02:49.140]  some threat emulation as we're working through these networks
[02:49.140 --> 02:54.660]  and use a lot of the common techniques that we see being
[02:54.660 --> 03:03.300]  used against ICS environments. And of course, tactics,
[03:03.300 --> 03:08.380]  techniques and procedures are part of the equation. But we
[03:08.380 --> 03:11.140]  find these really change depending on the environment
[03:11.140 --> 03:15.160]  that you have. And it's important to, of course, start
[03:15.160 --> 03:18.020]  with understanding what you have, whether you're running
[03:18.020 --> 03:21.200]  Windows Active Directory or Windows Workgroup, what kind of
[03:21.200 --> 03:25.300]  security controls you have, how the internet access works, how
[03:25.300 --> 03:28.860]  industrial vendors get in, what your firewall rules look like.
[03:28.860 --> 03:33.880]  Once you understand these basic environmental factors, and
[03:33.880 --> 03:38.020]  understand how they change the tactics and techniques of an
[03:38.020 --> 03:42.280]  activity group, that can really help you reduce your risk and
[03:42.280 --> 03:46.600]  understand where you need to invest your time and energy to
[03:46.600 --> 03:52.000]  mitigate some of these risks. Of course, if you if you study
[03:52.000 --> 03:56.000]  activity groups like Electrum and Xenotime, there are publicly
[03:56.000 --> 04:01.720]  known techniques that they have used against environments. And I
[04:01.720 --> 04:04.080]  certainly believe those techniques would change
[04:04.080 --> 04:08.000]  depending on what was available. As a pen tester, as an
[04:08.000 --> 04:11.640]  adversary, we're always very dynamic with our approach, we
[04:11.640 --> 04:17.400]  need to roll with the punches and adjust our techniques to
[04:17.400 --> 04:21.720]  align with the environment we're faced with. So that's why it's
[04:21.720 --> 04:24.800]  not one size fits all, you can't take all these TTPs that are
[04:24.800 --> 04:28.840]  identified and directly apply them to your environment
[04:28.840 --> 04:33.540]  necessarily. Often the environment dictates what the
[04:33.540 --> 04:40.060]  TTPs are going to be used, which TTPs are going to be used. So
[04:40.060 --> 04:43.980]  during this presentation, we'll be talking about our top five
[04:43.980 --> 04:48.280]  ICS assessment findings for 2019. These are related to
[04:48.280 --> 04:52.020]  firewall rules, access management, system hardening,
[04:52.020 --> 04:55.100]  logging and network visibility. So we'll be talking about some
[04:55.100 --> 04:58.160]  of the tools that we use as penetration testers and ICS
[04:58.160 --> 05:01.940]  network assessment professionals, some of the tools
[05:01.940 --> 05:05.880]  that can be used safely in ICS environments without introducing
[05:06.760 --> 05:10.860]  operational risk or very, at the very least, minimal operational
[05:10.860 --> 05:15.800]  risk when they are being leveraged in these environments,
[05:15.800 --> 05:19.200]  how to identify these risks using these tools, and then also
[05:19.200 --> 05:24.680]  how to mitigate some of these common findings. So at the end
[05:24.680 --> 05:29.820]  of the day, if you're able to take ownership of your
[05:29.820 --> 05:34.540]  industrial cybersecurity posture, do some self assessment
[05:34.540 --> 05:38.340]  work. It's not difficult to do once you understand what tools
[05:38.340 --> 05:43.900]  are available and how to approach some of these problems
[05:44.420 --> 05:47.080]  and highlight some of these problems. If you're able to
[05:47.080 --> 05:51.200]  mitigate a lot of these common issues, even prior to doing
[05:51.200 --> 05:54.200]  another assessment, it allows that red team or that
[05:54.200 --> 05:57.400]  penetration testing team or that assessment team to really focus
[05:57.400 --> 06:00.080]  on the more interesting problems. So you're getting rid
[06:00.080 --> 06:04.140]  of all the low hanging fruit. So the adversary group has to dig
[06:04.220 --> 06:08.260]  a lot deeper and focus on some of the more challenging
[06:08.260 --> 06:13.080]  problems. And you're also raising the bar like when you
[06:13.080 --> 06:16.180]  when you address a lot of these low hanging fruit, a lot of
[06:16.180 --> 06:22.260]  these low level issues, it really reduces the playbook that
[06:22.260 --> 06:27.440]  the adversary can can use. They're not able to fall back on
[06:27.440 --> 06:33.120]  their normal, normal operating plans, they need to think
[06:33.120 --> 06:35.920]  outside the box a little more, they need to experiment more, do
[06:35.920 --> 06:38.280]  more reconnaissance. And whenever they do that, when they
[06:38.280 --> 06:42.400]  have to work harder, you have more opportunities to detect
[06:42.400 --> 06:45.800]  them, you have more opportunities to stop them. And
[06:48.460 --> 06:51.140]  and also you make their lives a lot more difficult, which is,
[06:51.140 --> 06:53.840]  you know, something you want to do. You want these, these
[06:53.840 --> 06:56.860]  adversaries who are targeting critical infrastructure, who
[06:56.860 --> 06:59.800]  are trying to turn the lights off in your in your town or, or
[06:59.800 --> 07:04.540]  impact these important industrial processes, you want
[07:04.540 --> 07:07.960]  them to have to lay in bed at night, questioning their life
[07:07.960 --> 07:12.220]  choices that brought them to that position of why they're
[07:12.220 --> 07:16.680]  targeting civilian infrastructure. So starting off
[07:16.680 --> 07:21.120]  with firewall rules, what we see when we do these assessments,
[07:21.120 --> 07:26.880]  often will ask for the the rules to be shared with us. Usually
[07:26.880 --> 07:31.680]  like a white box approach is best. When we're doing ICS
[07:31.680 --> 07:34.860]  assessments, we really need to be transparent with the
[07:34.860 --> 07:39.940]  operating operators, the sites, and the site personnel. Turns
[07:39.940 --> 07:44.220]  out, industrial asset owners and industrial operators don't like
[07:44.220 --> 07:49.140]  surprises. So we found that it's very important to be open and
[07:49.140 --> 07:52.280]  clear with what we're doing, whenever we're doing it within
[07:52.280 --> 07:57.900]  these ICS assessments. The more information we can share, the
[07:57.900 --> 08:02.640]  more we can work closely with the operations team and start to
[08:02.640 --> 08:07.680]  build that trust and that build that bridge between the
[08:08.320 --> 08:12.900]  cybersecurity team and the OT or the ICS operations team, which
[08:12.900 --> 08:16.660]  is which is so important to be successful in this environment.
[08:16.800 --> 08:20.600]  So when we ask for these firewall rules, we'll usually
[08:20.600 --> 08:26.180]  use a tool to make sense of them. There's dozens of different
[08:26.180 --> 08:30.100]  firewalls out there and they all provide their rules in different
[08:30.100 --> 08:33.280]  formats. Fortunately, there are some commercial tools that you
[08:33.280 --> 08:36.880]  can use and even some free tools you can use to make sense of
[08:36.880 --> 08:39.600]  these rules and work through them in more of an Excel
[08:39.600 --> 08:44.240]  spreadsheet kind of format. One free tool we like to use is the
[08:44.240 --> 08:48.980]  SolarWinds free firewall browser. So what you can do is
[08:48.980 --> 08:52.500]  export your firewall rules and then import them using this
[08:52.500 --> 08:57.120]  SolarWinds free firewall browser and then just go kind of line by
[08:57.120 --> 09:02.440]  line. What you're really looking for is interactive protocols
[09:02.440 --> 09:08.780]  that allow remote access between your different trust zones. So
[09:08.780 --> 09:12.740]  typically between your corporate network and your ICS network, or
[09:12.740 --> 09:15.850]  even between different trust zones within the ICS network.
[09:16.430 --> 09:20.770]  You're looking for SSH, Telnet, remote desktop, VNC, even things
[09:20.770 --> 09:27.430]  like WMI or remote management, RPC, SMB, even protocols like
[09:27.430 --> 09:33.490]  OPC, like OPCDA, the older OPC protocols can allow remote
[09:33.490 --> 09:42.510]  access and often do. So we often find there are temporary
[09:42.510 --> 09:49.530]  firewall rules still in these configurations from the time of
[09:49.530 --> 09:53.810]  commissioning, we find there's vendor dictated rules and vendor
[09:53.810 --> 09:56.110]  access rules that have never really been evaluated or
[09:56.110 --> 09:58.850]  questioned. So it's important to go line by line and really
[09:58.850 --> 10:01.390]  question why do we have this? Like what, what purpose does it
[10:01.390 --> 10:04.270]  serve? Who's using this? And to knock off as many of those
[10:04.270 --> 10:09.990]  temporary or vendor dictated rules as you can. Of course, you
[10:09.990 --> 10:12.890]  want to communicate with your vendor, if that vendor is using
[10:12.890 --> 10:18.270]  that for remote access, you want to identify those and make sure
[10:18.270 --> 10:22.270]  they are still able to access or maybe propose a more secure
[10:22.270 --> 10:27.950]  method if the method that you're using is introducing risk in
[10:27.950 --> 10:32.550]  your environment. So this is what the free firewall browser
[10:32.550 --> 10:36.850]  looks like. It just breaks down the rules line by line in sort
[10:36.850 --> 10:39.590]  of an Excel spreadsheet format. And you can see we've got a
[10:39.590 --> 10:44.530]  couple interesting interactive rules here on 3389, which is the
[10:44.530 --> 10:47.690]  remote desktop protocol. So things to watch out for when
[10:47.690 --> 10:51.230]  you're going through these assessments. There's commercial
[10:51.230 --> 10:54.130]  tools you can use as well like Nipper that can help you
[10:54.130 --> 11:00.990]  identify issues. Often we still find any rules or what's
[11:00.990 --> 11:03.850]  equivalent to any rules. Sometimes these firewall rules
[11:03.850 --> 11:08.210]  can get quite complicated. And you put enough rules overlapping
[11:08.210 --> 11:12.070]  on top of each other and it can basically equate to any rule.
[11:12.070 --> 11:15.170]  So it's important to study these firewall rules closely and
[11:15.170 --> 11:18.970]  identify opportunities to pivot through these different trust
[11:18.970 --> 11:25.570]  zones. Now another common issue that we run into is access
[11:25.570 --> 11:31.610]  management. And what we really find is it's not necessary most
[11:31.610 --> 11:40.210]  of the time to use any exploits or have to dig too deep in
[11:40.210 --> 11:47.430]  these ICS networks to pivot or escalate privilege because the
[11:47.430 --> 11:52.250]  access management is so poor in these environments. Often we'll
[11:52.250 --> 11:58.010]  run into shared Active Directory environments between corporate
[11:58.010 --> 12:03.730]  and the ICS. So once we take that corporate Active Directory
[12:03.730 --> 12:06.190]  environment, we're able to easily pivot and take full
[12:06.190 --> 12:09.810]  control over the ICS environment. Other situations where there is
[12:09.970 --> 12:13.290]  a dedicated Active Directory environment in the ICS, it's
[12:13.290 --> 12:17.970]  poorly maintained and hasn't really been configured properly.
[12:17.970 --> 12:21.330]  So usually we see almost everybody's a domain admin or
[12:21.330 --> 12:24.430]  there's lots of service accounts that are domain admins. Lots of
[12:24.430 --> 12:29.790]  these common issues in Active Directory that we run into. So
[12:29.790 --> 12:32.990]  what do you do? How do you identify these issues? Well, what
[12:32.990 --> 12:37.690]  we typically do is run a tool called Bloodhound. Now it's a
[12:37.690 --> 12:43.350]  free open source tool and it's been used by pen testing teams
[12:43.350 --> 12:49.450]  and red teams to unravel the yarn ball that is Active
[12:49.450 --> 12:53.190]  Directory. For years, Active Directory kind of experienced
[12:53.190 --> 12:57.650]  this security through obscurity where it's so complicated that
[12:57.650 --> 13:00.850]  even the adversaries couldn't really figure out all of the
[13:00.850 --> 13:03.810]  groups and groups and users and groups and how all those
[13:03.810 --> 13:06.570]  unwind to different permission levels. But with the
[13:06.570 --> 13:10.670]  introduction of Bloodhound, this tool uses graph theory to
[13:11.370 --> 13:14.490]  really map out what the implications of all these
[13:14.490 --> 13:19.050]  permissions are, how to unravel all these groups to determine
[13:19.050 --> 13:22.670]  who's really a domain admin and how you can pivot from the
[13:22.670 --> 13:26.870]  average user to domain admin fairly easily. So it shows you
[13:26.870 --> 13:29.430]  all these different paths and overprivileged accounts that
[13:29.430 --> 13:32.570]  you can identify and potentially lock down. And it's fairly
[13:32.570 --> 13:35.830]  safe, too. There's a very low operational risk because it
[13:35.830 --> 13:39.330]  only communicates with the Active Directory server in the
[13:39.330 --> 13:41.850]  network. It's not going to scan your network or hit all the
[13:41.850 --> 13:44.590]  PLCs in your network or anything like that. It's only going to
[13:44.590 --> 13:48.590]  communicate with the Active Directory environment. And it's
[13:48.590 --> 13:51.870]  only going to send LDAP requests, which are fairly
[13:51.870 --> 13:55.270]  normal. It's just the same kind of network activity that you
[13:55.270 --> 13:59.390]  would introduce if you were logging into a machine or remote
[13:59.390 --> 14:03.470]  desktoping into a machine. It's nothing unusual for that
[14:03.470 --> 14:08.430]  environment. There's certainly a big spike of LDAP when you use
[14:08.430 --> 14:11.510]  that tool, but it's nothing that would create an operational
[14:11.510 --> 14:16.690]  risk in that environment. So what does that look like? So
[14:16.690 --> 14:21.430]  here's an example of Bloodhound unraveling a path to the domain
[14:21.430 --> 14:26.490]  admin from this RTAM user. We can see he's a member of this
[14:26.490 --> 14:30.630]  group that's an administrator on this machine. And because
[14:30.630 --> 14:36.150]  they're an admin on this machine, they're able to gain
[14:36.730 --> 14:45.170]  access to potentially the password or the hash of this
[14:45.170 --> 14:48.150]  user who is also logged into this machine, and then use that
[14:48.150 --> 14:53.950]  user's privilege to gain domain administrator access in that
[14:53.950 --> 14:57.450]  network. So this can really make sense of Active Directory and
[14:57.450 --> 15:01.350]  help identify some of those common issues and common
[15:01.350 --> 15:05.410]  misconfigurations. So access management part two. So what if
[15:05.410 --> 15:08.270]  you don't have Active Directory? What if it's a Windows work
[15:08.270 --> 15:11.850]  group environment, which is also fairly common to see in ICS? And
[15:11.850 --> 15:15.150]  even if you do have Active Directory, there's other
[15:15.150 --> 15:18.430]  passwords that exist outside of Active Directory within these
[15:18.430 --> 15:23.150]  ICS networks. So I'm talking about things like VNC and SSH,
[15:23.150 --> 15:28.670]  credentials into switchgear, networkgear, stuff like that.
[15:28.750 --> 15:32.170]  There's usually passwords just laying around the network and
[15:32.170 --> 15:36.710]  Excel spreadsheets or notepad files or default credentials for
[15:36.850 --> 15:41.830]  a lot of devices. Often we find credentials are stored in things
[15:41.830 --> 15:47.530]  like Chrome or stored in things like Putty or WinSCP or
[15:47.530 --> 15:52.470]  BatchPatch, or other other tools like that. And when you when you
[15:52.470 --> 15:56.070]  click that option to save your username and password in these
[15:56.070 --> 16:00.650]  tools, these tools don't always securely manage those
[16:00.650 --> 16:04.270]  credentials. So it can be quite trivial for an attacker to pull
[16:04.270 --> 16:09.930]  out those stored credentials. So what you can do is leverage some
[16:09.930 --> 16:15.250]  of these client side tools, like Session Gopher that are
[16:15.250 --> 16:19.830]  free, Session Gopher from FireEye, or even performing
[16:19.830 --> 16:23.770]  things like an LSAS dump, or using tools like Mimi Cats, Mimi
[16:23.770 --> 16:27.570]  Kittens, and some of these Nirsoft password utils. Now Mimi
[16:27.570 --> 16:30.490]  Cats is it's something that's used by almost every activity
[16:30.490 --> 16:35.830]  group. Once these activity groups get a foothold in an
[16:35.830 --> 16:38.850]  environment, one of the first things they do is dump their
[16:38.850 --> 16:42.590]  post exploitation tools. A lot of those are just trying to find
[16:42.590 --> 16:46.910]  passwords to escalate privilege and move laterally in that
[16:46.910 --> 16:50.010]  environment. So you want to try to understand how you're storing
[16:50.010 --> 16:52.150]  your passwords, what passwords are stored on different
[16:52.150 --> 16:55.450]  endpoints. And you can automate that process just like the
[16:55.450 --> 17:01.010]  activity groups typically do. So what can you do once you've
[17:01.010 --> 17:07.870]  identified the issues or the mis-storage of passwords, you
[17:07.870 --> 17:13.590]  can implement some kind of password storage mechanism, or
[17:14.110 --> 17:16.790]  a privileged access management system, or even just like a
[17:16.790 --> 17:22.650]  vault, or a last pass, or some password vault solution that
[17:22.770 --> 17:27.110]  does a better job protecting these important credentials than
[17:28.610 --> 17:36.210]  WinSCP, or Putty, or other tools typically do. So here's a quick
[17:36.210 --> 17:37.510]  example of running Mimi Cats. And it's something I'd
[17:37.510 --> 17:43.610]  recommend. It's something we always try to do on a safe
[17:43.610 --> 17:48.510]  environment, running Mimi Cats, just to see if it's detected, if
[17:48.510 --> 17:53.630]  it triggers any kind of alerts. If we're able to do like what
[17:53.630 --> 18:00.950]  we're doing here, dump the LSAS memory to a file. So if we dump
[18:00.950 --> 18:05.410]  the LSAS memory using the task manager, just right click on the
[18:06.670 --> 18:11.090]  local security authority process and go create dump file, we can
[18:11.090 --> 18:15.250]  copy that dump file off of the machine and run it through Mimi
[18:15.250 --> 18:18.650]  Cats to see what kind of passwords we pull out of memory.
[18:18.650 --> 18:24.690]  If your Windows endpoints are not hardened, you'll usually be
[18:24.690 --> 18:31.950]  able to pull out the hashes and often clear text passwords from
[18:31.950 --> 18:35.390]  any account that has recently logged into that machine. So
[18:35.390 --> 18:38.830]  it can be quite eye opening to to see that and see these
[18:38.830 --> 18:42.430]  passwords coming through in clear text using Mimi Cats. So
[18:42.430 --> 18:47.330]  it's something we we recommend that our customers do in a safe
[18:47.330 --> 18:51.790]  and safe manner. And even just copying the Mimi Cats
[18:51.790 --> 18:55.450]  executable into one of your ICS assets just to see if it gets
[18:55.450 --> 18:58.870]  caught by Windows Defender or Norton AV and, and to see if
[18:58.870 --> 19:03.330]  that alert makes it someplace to see if you know the your
[19:04.950 --> 19:08.910]  monitoring is set up properly. It should create alerts, it
[19:08.910 --> 19:11.290]  should set off all kinds of alarm bells. So it's a great way
[19:11.290 --> 19:18.590]  of testing your, your monitoring, or malicious files
[19:18.590 --> 19:23.830]  in your ICS network. Here's another example of another tool
[19:23.830 --> 19:28.010]  the FireEye Session Gopher, it looks for passwords and other
[19:28.010 --> 19:34.270]  tools like WinSCP and PuTTY and RDP, like your stored passwords
[19:34.270 --> 19:39.990]  in your remote desktop client. So it'll pull out clear passwords
[19:39.990 --> 19:43.070]  like we see in this example below. And this can be very
[19:43.070 --> 19:46.670]  valuable to an adversary who's looking to move laterally or
[19:46.670 --> 19:49.890]  escalate their privilege in the network. And we almost always,
[19:49.890 --> 19:53.290]  always find credentials when we're doing these assessments.
[19:53.290 --> 19:56.350]  One way or another, there's there's always, almost always
[19:56.870 --> 20:01.410]  poor storage of these credentials. So another thing
[20:01.410 --> 20:06.330]  that can help address that credential storage issue is some
[20:06.950 --> 20:11.210]  basic Windows system hardening. It's a very common issue that we
[20:11.210 --> 20:14.850]  see where a lot of these ICS Windows assets, they haven't
[20:14.850 --> 20:18.290]  performed any hardening. Often we find things like the firewall
[20:18.290 --> 20:22.630]  is completely turned off on these Windows endpoints. Just
[20:22.630 --> 20:29.170]  because these ICS networks are so sensitive at times, once the
[20:29.170 --> 20:33.690]  operators or the system integrators get things working,
[20:33.690 --> 20:36.350]  they're afraid to change anything or lock anything down
[20:36.350 --> 20:41.590]  in case it breaks something. So usually, once they get things
[20:41.590 --> 20:45.410]  working, they just kind of leave it as is. And it's rare to find
[20:45.410 --> 20:49.190]  any system hardening really performed. And without some
[20:49.190 --> 20:53.070]  basic Windows system hardening, it's so easy to cut through
[20:53.070 --> 20:57.350]  those networks as an adversary. The default Windows
[20:58.270 --> 21:01.990]  installation, especially Windows 7 and older Windows versions,
[21:01.990 --> 21:07.390]  there's just so many backwards compatibility features that are
[21:07.390 --> 21:10.670]  turned on that make it so easy to pull passwords, escalate
[21:10.670 --> 21:15.950]  privilege to a system that once you're in that network, you can
[21:16.480 --> 21:20.510]  own it within a matter of minutes without some system
[21:20.510 --> 21:41.040]  hardening happening. Oops, looks like my internet connection had
[21:41.120 --> 21:44.340]  a bit of a blip there. I'll start that over. Now system
[21:44.340 --> 21:48.140]  hardening does have the potential to create an operational
[21:48.140 --> 21:51.820]  or introduce operational risk, you'll need to work closely with
[21:51.820 --> 21:55.480]  your vendor to ensure that any hardening you're doing won't
[21:55.480 --> 22:00.840]  impact your operating process. Often, the major vendors will
[22:00.840 --> 22:05.220]  have system hardening guides that you can follow, and the
[22:05.220 --> 22:11.040]  recommended hardening that they have tested and approved. So
[22:11.040 --> 22:13.420]  it's important when you're building a new greenfield
[22:13.420 --> 22:17.020]  system, when you're building an ICS system from the ground up
[22:17.020 --> 22:21.820]  to ask them to implement these system hardening features to
[22:21.820 --> 22:25.880]  turn security on. Because what we find is if you don't ask the
[22:25.880 --> 22:27.900]  vendors or the system integrators to do these things,
[22:27.900 --> 22:32.540]  it just doesn't happen. If you don't set that standard or make
[22:32.540 --> 22:36.800]  that request, they're not going to do it. So it's very important
[22:36.800 --> 22:40.540]  to be clear that you want the systems hardened, they need to
[22:40.540 --> 22:44.360]  be part of their commissioning plan, part of their site
[22:44.360 --> 22:47.320]  acceptance testing or factory acceptance testing checklist,
[22:47.320 --> 22:51.960]  that these hardening features are turned on and the
[22:51.960 --> 22:54.700]  recommended best practices for system hardening for that vendor
[22:54.700 --> 22:59.420]  have been implemented. And if the vendor does not, if they're
[22:59.420 --> 23:04.380]  not very mature, and they don't have a hardening guide, you can
[23:05.840 --> 23:10.860]  you can use some of the tools like some of the ones I've
[23:10.860 --> 23:13.600]  listed here, like CHAPS, the configuration hardening
[23:13.600 --> 23:19.240]  assessment, PowerShell script from Cutaway Security, to
[23:19.240 --> 23:23.460]  identify some of the common hardening issues. And you can
[23:23.460 --> 23:30.040]  raise those up with the vendor to get them approved or ensure
[23:30.040 --> 23:36.380]  that they're on board with making these changes. But
[23:36.380 --> 23:39.280]  there's other tools, Microsoft has a great tool called the
[23:39.280 --> 23:41.940]  Security Compliance Toolkit, which does a very thorough
[23:41.940 --> 23:44.940]  analysis, it does require you to install some software in your
[23:44.940 --> 23:48.160]  ICS environments that could cause some issues with your
[23:48.160 --> 23:51.180]  vendors, same with the CIS tools and the state tools, they do
[23:51.180 --> 23:54.980]  require software to be installed in order to make them work. But
[23:54.980 --> 23:57.080]  that's why I love the CHAPS tool, it's just a PowerShell
[23:57.080 --> 23:59.580]  script you can run, it doesn't require any software to be
[23:59.580 --> 24:04.180]  installed, it just will do some data collection on that endpoint
[24:04.900 --> 24:09.520]  and highlight some of these common hardening issues. So
[24:09.520 --> 24:11.680]  again, you have to work closely with the vendor when you're
[24:11.680 --> 24:13.780]  running these things. But here's an example of the CHAPS
[24:13.780 --> 24:22.620]  hardening demo in action. You can just run it as a PowerShell
[24:22.620 --> 24:26.600]  command, like I've done above. And then it gives you sort of a
[24:26.600 --> 24:31.500]  pass fail view, things like W digest DNS client, this, if you
[24:31.500 --> 24:35.440]  implement these hardening recommendations, it will prevent
[24:35.440 --> 24:39.160]  an adversary from being able to pull clear text passwords out of
[24:39.160 --> 24:45.200]  memory, clear hashes out of memory. It'll prevent them from
[24:45.200 --> 24:47.860]  downgrading to PowerShell 2 and bypassing a lot of the
[24:47.860 --> 24:53.180]  PowerShell security features. So it also helps reduce the chances
[24:53.180 --> 24:55.740]  of man-in-the-middle attacks and things like that in your ICS
[24:55.740 --> 24:59.720]  network. So just a little bit of hardening and lockdown can have
[24:59.840 --> 25:07.900]  a huge impact. So what we're seeing from a logging
[25:07.900 --> 25:11.820]  perspective is usually a complete lack of logging, or no
[25:11.820 --> 25:14.520]  centralized logging. Sometimes logging is turned on on the
[25:14.520 --> 25:16.640]  Windows endpoints, but it's just not going anywhere. It's just
[25:16.640 --> 25:21.460]  being stored locally. And if it is turned on and being centrally
[25:21.460 --> 25:25.660]  managed, they're not always logging the right stuff. In
[25:25.660 --> 25:28.640]  these ICS environments, they're not logging PowerShell commands
[25:28.640 --> 25:32.300]  or, or new processes. They're not using things like sysmon to
[25:32.300 --> 25:37.120]  really get the details you need to do proper forensic analysis
[25:37.120 --> 25:41.180]  and incident response in these environments. And it's not hard
[25:41.180 --> 25:46.280]  to do, it's not difficult to turn these, these things on. And
[25:46.280 --> 25:49.820]  again, that CHAPS tool can help you identify some of the common
[25:50.400 --> 25:54.060]  logging issues that you may encounter and some of the things
[25:54.060 --> 25:58.580]  you'll want to turn on in your ICS environments. And really
[25:58.580 --> 26:02.220]  just having that centrally managed logging environment can
[26:02.220 --> 26:07.000]  be such a huge win. If you ever are doing like an incident
[26:07.000 --> 26:11.560]  response, you'll be so grateful to have that centrally managed
[26:11.560 --> 26:14.080]  logging environment. And it's all built into Windows, you
[26:14.080 --> 26:16.180]  don't need to have Splunk or anything like that. You can just
[26:16.180 --> 26:20.560]  use Windows Event Forwarding to centrally manage those those
[26:20.560 --> 26:23.560]  Windows events without having to spend any extra money. Just
[26:23.560 --> 26:27.900]  having that those events all in one place can really facilitate
[26:27.900 --> 26:32.140]  things like threat hunting, and can speed up incident response
[26:32.140 --> 26:38.320]  and give you better visibility into your ICS network as well.
[26:38.860 --> 26:43.500]  So what we recommend is understanding what your Windows
[26:43.500 --> 26:47.160]  event logging capabilities are today, what's being logged,
[26:47.160 --> 26:50.520]  what's not being logged, where is it going, and using again,
[26:50.520 --> 26:55.140]  that CHAPS tool can help identify these issues. There's
[26:55.140 --> 26:58.460]  really a pretty low operational risk. It may produce a little
[26:58.460 --> 27:02.060]  more traffic on your network. But for most modern networks,
[27:02.060 --> 27:09.240]  this shouldn't be a huge issue. Now here's the output of that
[27:09.240 --> 27:13.360]  CHAPS tool again, that PowerShell script. And it can
[27:13.360 --> 27:19.420]  show you some of the issues if you have the PowerShell task
[27:19.420 --> 27:25.680]  scheduler, WinRM, WMI activity, all these different log files
[27:25.680 --> 27:31.460]  are important to have turned on and have a larger log size and
[27:31.460 --> 27:33.080]  ensure that they're being forwarded to a central
[27:33.080 --> 27:36.180]  location. So the CHAPS tool can help identify a lot of these
[27:36.180 --> 27:41.580]  common issues. So if you turn on the recommended logging from
[27:41.580 --> 27:44.980]  CHAPS, it will make a big difference and reduce your risk
[27:44.980 --> 27:51.380]  quite a bit. Now on to network visibility. Another common
[27:51.380 --> 27:57.120]  issue that we see is, as a pen test or a red team, we're able
[27:57.120 --> 28:01.360]  to operate within these ICS networks undetected. Once we're
[28:01.360 --> 28:04.500]  in them, there's usually very little or no visibility. So we
[28:04.500 --> 28:09.760]  can move about, move laterally, escalate privilege, take over
[28:09.760 --> 28:16.260]  the domain without any alarm bells going off, and maintain
[28:16.260 --> 28:23.020]  perpetual access as well. So what you can do is, if you don't
[28:23.020 --> 28:26.380]  have network visibility today, you can start to lay that
[28:26.380 --> 28:32.440]  foundation and start to see if you get the value out of it in a
[28:32.440 --> 28:37.820]  low cost sort of introductory kind of method. First of all, if
[28:37.820 --> 28:43.400]  you just identify the points in your network that you should be
[28:43.400 --> 28:46.560]  monitoring, what switches you should be attaching or
[28:46.560 --> 28:50.700]  configuring SPAN ports to, or better yet, purchase some
[28:50.700 --> 28:54.960]  network TAPs and install them. And just having those, just
[28:54.960 --> 28:58.080]  having them in your network that you can tap into to collect data
[28:58.080 --> 29:02.380]  and collect PCAPs, it's extremely valuable in an incident
[29:02.380 --> 29:05.980]  response, or it's extremely valuable in a threat hunting
[29:05.980 --> 29:10.700]  exercise. So that can really enable your security operations
[29:10.700 --> 29:15.820]  team to do a lot more, just knowing where to plug in. That's
[29:15.820 --> 29:18.420]  the first step in getting that network visibility. And once you
[29:18.420 --> 29:21.120]  have that, you can start to collect PCAPs and do some
[29:21.120 --> 29:23.680]  analysis to better understand what's going on, what kind of
[29:23.680 --> 29:26.860]  traffic you see in your network, what's normal. And then
[29:26.860 --> 29:29.460]  you can start to use some, even some free tools that are
[29:29.460 --> 29:34.820]  available, or commercial tools to perform analysis on those
[29:34.820 --> 29:38.920]  PCAPs, or even install some hardware and software to do
[29:38.920 --> 29:45.320]  continuous monitoring of that network traffic. And again, it's
[29:45.400 --> 29:49.800]  a pretty low operational risk. You're connecting to SPAN ports
[29:51.400 --> 29:56.200]  or TAPs. Now, ideally, we always recommend you use dedicated
[29:56.200 --> 30:01.700]  TAPs, network TAPs rather than SPAN ports. SPAN ports, when
[30:01.700 --> 30:04.780]  they're configured on a switch, there is a risk that that switch
[30:04.780 --> 30:07.400]  can get kind of overloaded, especially if it's an older
[30:07.400 --> 30:11.460]  piece of equipment. You should be monitoring the CPU usage of
[30:11.460 --> 30:15.340]  those switches. Once you enable your SPAN port, if they're in
[30:15.340 --> 30:21.760]  the 80% or 90% utilization, kind of threshold, you may want
[30:21.760 --> 30:26.580]  to consider an alternate option, because that could just put it
[30:26.580 --> 30:30.520]  over the edge and create a network outage. So you need to
[30:30.520 --> 30:33.280]  need to be a little careful with that. But it shouldn't, it
[30:33.280 --> 30:40.940]  typically doesn't cause too many issues to set up those SPAN
[30:40.940 --> 30:44.320]  ports. But in some of the edge cases, it could create some or
[30:44.320 --> 30:46.560]  introduce some operational risks. So something to be aware
[30:46.560 --> 30:51.780]  of, something to watch. And of course, having visibility in
[30:51.780 --> 30:55.020]  your network can improve your threat detection and threat
[30:55.020 --> 30:59.560]  monitoring capability with the right tools and techniques and
[30:59.560 --> 31:06.340]  procedures. So there are two free products that Dragos
[31:07.040 --> 31:12.240]  provides. One of the free products is our old Cyber Lens
[31:12.240 --> 31:16.520]  product, which is it's well suited for PCAP analysis. It was
[31:16.520 --> 31:21.060]  really designed to just take a PCAP and help visualize what's
[31:21.060 --> 31:26.000]  inside, specific to the ICS protocols and ICS content. It's
[31:26.100 --> 31:29.100]  a great way to help you understand what assets are in
[31:29.100 --> 31:32.260]  your network. That's a common challenge we see in the ICS
[31:32.260 --> 31:36.440]  space. What do I have? What's on my network at any given time? So
[31:36.440 --> 31:40.320]  Cyber Lens can help you identify those. And Sophia is designed
[31:40.320 --> 31:46.300]  for more of the continuous monitoring. Sophia was the next
[31:46.300 --> 31:49.980]  defense product that was commercially sold to customers
[31:49.980 --> 31:53.900]  all around the world. And now it's available for free from the
[31:53.900 --> 31:56.580]  Dragos website. So if you want just continuous asset
[31:56.580 --> 31:59.740]  identification, monitoring just to know what's on your network
[31:59.740 --> 32:02.500]  and have that updated perpetually, Sophia is a great
[32:02.500 --> 32:06.340]  tool for doing that. And of course, there's commercial tools
[32:06.340 --> 32:11.480]  you can use, like Network Miner to do analysis of PCAPs. That's
[32:11.560 --> 32:16.160]  a very handy tool for digging into PCAP data. And of course,
[32:16.160 --> 32:20.120]  the Dragos platform is our commercial product that does a
[32:20.120 --> 32:28.640]  threat-based monitoring of ICS networks with playbooks and
[32:28.640 --> 32:32.660]  feeds into our Intel with the latest activity groups that are
[32:32.660 --> 32:37.200]  targeting these environments. So if you're ready, if you're
[32:37.200 --> 32:42.920]  seeing the value in your network monitoring, then maybe a
[32:42.920 --> 32:46.180]  commercial product is the next step for you. But it's always
[32:46.180 --> 32:50.000]  nice to kind of learn to walk before you run, kind of identify
[32:50.000 --> 32:54.420]  those spam ports and kind of ease your way into it to make
[32:54.420 --> 32:58.520]  sure you really see the value and take full advantage of that
[32:58.520 --> 33:06.520]  value of OT network monitoring. And of course, this is
[33:06.520 --> 33:12.820]  something these self-checks, these common self-assessments
[33:12.820 --> 33:18.040]  can be done regularly. And there's there's huge benefits to
[33:18.040 --> 33:20.420]  taking ownership of these, just doing like some mini
[33:20.420 --> 33:24.120]  assessments once a year, once every six months, just to see
[33:24.120 --> 33:27.720]  what's on your network, look at how passwords are stored,
[33:27.720 --> 33:34.280]  understand who the big accounts in your Active Directory
[33:34.280 --> 33:37.660]  environment are, who the domain admins are, and who has access
[33:37.660 --> 33:41.560]  to that. All these things should be done regularly. Once you
[33:41.560 --> 33:44.800]  really take ownership of your industrial cybersecurity, of
[33:44.800 --> 33:49.560]  your industrial cyber risk, you can make a big difference in
[33:49.560 --> 33:53.600]  that risk reduction. You can start to address that. And it's
[33:53.600 --> 33:58.020]  something that should be done on a regular basis, at a set
[33:58.020 --> 34:01.080]  interval once a year, once every six months, because ICS
[34:01.080 --> 34:04.620]  environments are quite dynamic, they do change. They're
[34:04.620 --> 34:10.240]  constantly being modified and updated and maintained. So it's
[34:10.240 --> 34:13.740]  good to do this on a regular basis. And it can be augmented
[34:13.740 --> 34:17.040]  once you get into this self-check and you're covering
[34:17.040 --> 34:20.340]  off a lot of the low hanging fruit. That's when you can bring
[34:20.340 --> 34:24.080]  in a professional team to do an assessment. And then they'll get
[34:24.080 --> 34:26.760]  to really dig into the interesting stuff, the stuff
[34:26.760 --> 34:32.460]  that is uncommon and would require an adversary to dig a
[34:32.460 --> 34:37.800]  little deeper, do more research, and have to sweat a little to
[34:37.800 --> 34:43.120]  move through your network. And that's the end of my
[34:43.120 --> 34:46.160]  presentation. Thank you so much for attending.
